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VEMMI URL Specification 

Status of this Memo 
This document specifies an Internet standards track protocol for the 
Internet community, and requests discussion and suggestions for 


improvements. Please refer to the current edition of the "Internet 
Official Protocol Standards" (STD 1) for the standardization state 


and status of this protocol. Distribution of this memo is unlimited. 


1) Abstract 


A new URL scheme, "vemmi" is defined. It allows VEMMI client software 


and VEMMI terminals to connect to multimedia interactive services 
compliant to the VEMMI standard (Enhanced Man-Machine Interface for 
Videotex and Multimedia/Hypermedia Information Retrieval Services), 
sometimes abbreviated as "VErsatile MultiMedia Interface". 


VEMMI is a new international standard for on-line multimedia 
services, that is both an ITU-T (International Telecommunications 
Union, ex. CCITT) International Standard (T.107) [2] and an 
European Standard (ETSI European Telecommunications Standard 


Institute) standard (ETS 300 382 [3], obsoleted by ETS 300 709 [1]). 


VEMMI could be described as an on-line multimedia protocol describing 


both the man-machine interface and the client/server exchange 
protocol. VEMMI operates usually on a single continuous session 
between a client and a host and supports an object-oriented, event- 
driven, client/server oriented and platform independent multimedia 
interface. The well-known tcp port number 575 has been assigned by 
IANA to the VEMMI protocol [13]. 


A description of the VEMMI standard along with its last approved 
version is publicly available on the Web: see the URL 
http://www.etsi.fr/ecs/projects/vemmi/vemmi.htm). A presentation of 
VEMMI can be found on http://www.mctel.fr/VEMMI/vemmien_intro.html 
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2) 


VEMMI URL scheme utility and operability: 


— VEMMI service selection: A VEMMI multimedia server will listen on 


its VEMMI well-known port for incoming connections. The server 
could of course be engaged in many simultaneous connections, and 
after a connection is established, the terminal must be able to 
select the desired VEMMI application, as a same system may host 
different VEMMI applications. 

The best mechanism to fully describe the VEMMI service to activate 
is the URL mechanism. 

- Reporting user action to a remote server: The VEMMI protocol 
establishes a continuous TCP/IP link between the terminal and the 
server during the whole user session. During a session managing 
VEMMI objects, the user actions are usually reported back to the 
server using the VEMMI user data report mechanism that is an 
integral part of the VEMMI protocol. 

However, in some case, the URL mechanism may be required to send 
back reports to a remote host. VEMMI is for example able to display 
HTML documents within a multimedia display area in a VEMMI dialog 
box. these HTML documents may be managed either by the VEMMI server 
(acting as a proxy gateway) or directly by the client software that 
will issue itself the HTTP requests on the network and browse 
across documents on the Web as a standard Web browser (the link to 
the VEMMI server is kept and used for interacting with other VEMMI 
objects and components but the VEMMI server may not be informed of 
the user navigation on the Web inside the multimedia area). 

In such a case, the URL mechanism could also be used to report the 
user actions and commands within a HTML document to be reported to 
the VEMMI server or even another system. 

Extension of Web browsers: The VEMMI protocol is quite 
complementary to HITP/HTML used by Web browsers, and several 
networks operators have decided to support jointly Web and VEMMI 
(seen as complementary protocols). Thanks to the VEMMI URL, Web 
browsers will be able to activate a VEMMI client software module to 
start a VEMMI session to the requested service when the user 
activate a vemmi URL included in the HTML document. 


Description of the VEMMI scheme 

The VEMMI URL scheme is used to designate multimedia interactive 
services conforming to the VEMMI standard (ITU/T T.107 and ETS 300 
709). 


A VEMMI URL takes the form: 


vemmi://<host>:<port>/<vemmiservice>; 
<attribute>=<value> 


Mavrakis, et. al. Standards Track [Page 2] 


RFC 2122 VEMMI URL Specification March 1997 


as specified in Section 3.1. of RFC 1738. If :<port> is omitted, the 
port defaults to 575 (client software may choose to ignore the 
optional port number in order to increase security). The 
<vemmiservice> part is optional and may be omitted. 


This URL does not designate a data object, but rather a multimedia 
interactive service. A VEMMI service starts a multimedia session 
managing multimedia objects and interacting with the user during the 
session. To the difference of other stateless protocols, the link 
between the client and the server is usually maintained during the 
whole session (although in some cases other mechanisms may be used, 
see below). 


The <vemmiservice> is the name of the VEMMI service to activate. This 
field is not mandatory and could be omitted for example if the remote 
host manages only one VEMMI service or activates a VEMMI service by 
default when no service is specified. If this field is omitted in the 
URL and the server requests it, it is assumed that the VEMMI client 
software will prompt the user for it. 


In addition, after the <vemmiservice>, optional attributes and values 
(parameters) associated with the VEMMI service may be specified as 
part of the URL. When present, each parameter (attribute/value pair) 
is separated from each other and from the rest of the URL by a ";" 
(semicolon). The name of the attribute and its value are separated by 
a "=" (equal sign). If present, these fields are used to transmit 
additional data useful for service selection or to request to perform 
a specific processing. For example, the SUSERDATA field can be 
specified to transmit additional user-specified data to the VEMMI 
service. 


Client/server dialog during service selection 


The VEMMI client will interpret the VEMMI URL to connect to the 
remote host and to access the specified VEMMI service. After 
connecting to the remote system, the host may prompt the VEMMI client 
for service name and user identification. 


Before starting the VEMMI session, a VEMMI terminal is in ’standard’ 
mode and may display the data received from the network in a videotex 
or telnet terminal window. As the VEMMI session may be started 
anytime during an interactive videotex or telnet session, the VEMMI 
service selection is performed by a simple dialog between the client 
and the server. 


The service, username and password information are transmitted by the 
client software to the host in answer to the corresponding requests 
received from the host. The following behavior is expected from the 
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client: 

- wait for the optional request strings from the host server 
(’service:’, ‘’username:’ and ’password:’) and answer them 
(respectively by <vemmiservice> value defined in the URL and the 
<username> and <password> entered by the user if required). The 
terminal answer may be sent automatically if the answers are known 
(that is if they are specified in the URL or terminal 
configuration) or it may prompt the user for the needed 
informations. When parameters (attribute and value pairs) are 
present in the URL, these fields will be sent following the 
<vemmiservice> transmitted to the host in answer to the ’service:’ 
request received from the host, separated from the <vemmiservice> 
value by a semicolon. 

- the client answers must always be followed by a Carriage Return 
(CR). If a Line Feed (LF) is transmitted after the CR, it will be 
ignored by the server. 

—- in both cases, the server may echo the characters received from the 
client terminal, the received CR being echoed as CR LF. The server 
may echo the password characters as stars or any other scrambled 
output for safety purpose. 

- the client must also be ready to start the VEMMI session as soon 
as it receives the VEMMI_Open command. Before starting this VEMMI 
session, the terminal is in ’standard’ mode and may display the 
data received from the network in a videotex or telnet terminal 
window (this is the reason why the service, username and password 
data are requested by the server using a telnet or videotex 
compatible dialog). 


Should an error occur during VEMMI service activation, the remote 
host may inform the user by displaying the error cause. It is 
recommended that, when possible and applicable, the status code 


syntax described in HTTP [8] [9] be used to facilitate automatic 
processing by the client of the host answer during error or normal 
operation. 


If a VEMMI client software wants to request a VEMMI object without 
establishing a continuous VEMMI session, such a request may also be 
performed using a HTTP request for the vemmi object encoded using the 
Internet media type application/vemmi (pending registration by IANA 
[10]). In the same way, HTTP could be used in some cases to exchange 
data pertaining to a VEMMI session with or without setting the keep- 
alive keyword in the Connection header to request a persistent 
connection [9]. Protocol switching using the upgrade header field may 
be used in such case to switch to vemmi protocol [9]. This possible 
use of HTTP for VEMMI is not described in this document. 
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5) Proposed syntax 
The proposed BNF syntax is encoded as specified in RFC 1738 [5] [14]: 


; vemmi (see ITU-T T.107 and ETSI ETS 300 709) 


vemmiurl = "vemmi://" hostport [ "/" vemmiservice *[ parameter ] ] 
vemmiservice = *[ uchar | myn | won | wen | noa" | "g" | "=" ] 
parameter = ";" attribute "=" value 
attribute = *[ uchar | nym | won | wen | wan | "g" ] 
value = *[ uchar | myn | non | wen | wan | "g" ] 

This syntax: - allows the user to specify the remote host address by 


its name or numeric address. Although he could select a specific 
port, it is expected the information providers and VEMMI software 
will mostly use the port number assigned to VEMMI (575) [13]. For 
security reasons, the username and password could not be specified 
in the URL. 

- allows him to select a specific VEMMI service if the remote host 
manages several different VEMMI services. 

- allows also to send additional data to the service using the 
parameter syntax, either during the service selection phase or when 
the user selects a vemmi hyperlink within a HTML document displayed 
in a VEMMI multimedia area. To the difference of the params syntax 
used in [4], the parameter syntax requires each value to be labeled 
by an attribute. The parameter attribute names are case- 
insensitive. Parameter values may or may not be case-sensitive, 
depending on the attribute. 


All the values of fieldname beginning by a dollar ($) sign are 

reserved for specific use, including: 

— COMMAND: VEMMI command to be returned to the host when the VEMMI 
session do not use a continuous link. 

— SCONTEXTDATA: context data. 

— SOBJECT_REQUEST: requests the retransmission of a given VEMMI object. 

— SUSERDATA: user data specific by the user and to be processed by the 
VEMMI service. 


6) Examples: 
Some examples of VEMMI URLs along with the corresponding 
client/server dialog are presented below, they are for information 
only: 
a) A simple VEMMI URL and the corresponding dialog for a VEMMI 


service that does not enforce access control might be: 
URL: vemmi://zeus.mctel.fr/demo 
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In this case, the exchange between client and server will be as 
follow (the server requests are presented left, client answers 
right): 

service: demo 

200 OK {status code returned by the VEMMI host} 


b) The service name may be omitted (for example if the remote server 
hosts only one VEMMI service), and the URL might then be: 
URL: vemmi://zeus.mctel.fr 
In this case, the VEMMI interactive session is started immediately 
by the host without requesting first the service name (should the 
client receive a service request from the host, it will prompt the 
user for service name). 


c) The URL could not include the username and password. In this case, 
should they be requested by the host, the VEMMI client may use a 
default value specified for this service or prompt the user for 
them (for example it could propose anonymous and user e-mail 
address as defaults): 

URL: vemmi://mctel.fr/demo 
In this case, the exchange between client and server may be as 
follows (server requests at the left, client answers at the right): 
service: demo 


login: anonymous {user has been prompted for username} 
password: mavrakis@ties.itu.ch {user prompted for password} 
401 Unauthorized {an anonymous user is not allowed to 


access the service} 


d) Some services may use additional data transmitted in the parameter 
fields, for example: 
URL: vemmi://mctel.fr/demo; SUSERDATA=smith; account=1234 
If no access check is done by the host, the dialog might be: 
service: demo; SUSERDATA=smith; account=1234 
200 OK 
...Starting VEMMI session... 


Procedure to use when a VEMMI URL is encountered in a HTML document 
without VEMMI support: 


The VEMMI URL support may be built-in in some Web browsers, or 
offered by an associated software or plug-in interworking with the 
user browser, for example using the WWW_RegisterProtocol API command 
to register the new VEMMI protocol. 


When a Web browser encounters a VEMMI URL without having VEMMI support, 

two cases may occur: 

- some browsers will detect an unrecognized scheme and signal an 
unrecoverable error directly. 
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—- others will manage it as a relative URL [4] and will build a 
complete URL including the VEMMI URL and will request it from the 
host having sent the current document. In this case the host will 
usually return the error "not found". 


Among the mechanisms that could be used in order to offer a friendly 

interface to both users with and without VEMMI support: 

- when the second case occurs and the relative URL including the 
vemmi:// string is transmitted to the server, the HTTPD server may 
be modified in order to recognize such URL and to propose the 
downloading of a VEMMI client software. 

- the HTML document including the vemmi URL allowing to start the 
VEMMI session may propose both options, for example: 

If your browser supports VEMMI, directly 

<A HREF="vemmi://ares.mctel.fr/TEST">start the interactive 
multimedia service</A>, otherwise 

<A HREF="ftp://ftp.mctel.fr/vemmi.exe">download first a VEMMI 
client software</A>. 

- the application/vemmi MIME type is defined below (to allow for 
example exchange of vemmi objects). A possible way is for the 
server to look in the HTTP Accept header field and to deduce that if 
application/vemmi is supported, then the VEMMI support exists (in 
this case, application/vemmi is to be defined in the browser and 
associated with the vemmi decoder). 


8) Security Considerations: 


The VEMMI URL scheme is subject to the same security implications as 
the general URL scheme [5] [14], so the usual precautions outlined in 
[5] [14] apply (for example, it is not allowed to store the username 
and password in the URLs). 


Furthermore, among VEMMI objects that could be used during the 
interactive session, metacode objects (representing a sequence of 
VEMMI commands) and operative objects (they are executable programs 
to be run on the client platform) may be downloaded and/or started. 


In order to protect the user against the activation of an harmful 
operative object, it is strongly recommended that the users use the 
configuration menu of their VEMMI software to disable the option of 
running operative objects when receiving potentially unsafe VEMMI 
objects, or at least enable the option to request first user approval 
before starting the execution of an operative object. 


The VEMMI remote interactive services may vary widely in their access 
control policies; in practice, when a prompt for username or password 
is received, the VEMMI terminal should request them from the user. 
The VEMMI terminal implementation could support additional features, 
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9A) 


for example proposing by default "anonymous" as username and the user 
Internet e-mail address as password, or looking in an encrypted local 
database for user identification on this service. 


Such an identification mechanism using the username/password scheme 
is unsecure and is provided for backwards compatibility only. The 
VEMMI services requiring a safe identification procedure must rely on 
other alternative mechanisms (e.g. S/KEY or other). In numerous 
cases, the user identification procedure will be performed by the 
VEMMI service. 


application/vemmi MIME type 


VEMMI is a multimedia interactive service and VEMMI objects are 
usually exchanged through a continuous VEMMI multimedia session. 
However, VEMMI objects could also be transmitted and exchanged using 
other mechanisms, for example using HTTP, through e-mail, and so 
on... The assignment of a MIME media type application/vemmi will 
allow this transport and exchange of VEMMI objects, and this 
paragraph describes this MIME type. 


Furthermore, for Web browsers not supporting the addition of new URL 
protocol scheme, the VEMMI MIME type may also be used to transmit, 
instead of a VEMMI object, a text file containing the VEMMI URL to 
activate to connect to a VEMMI server. 


DESCRIPTION: 
MIME media type name: "application" 
MIME subtype name: "vemmi" 
Required parameters: none 
Optional parameters: 


— version: 
an optional version number may be specified, in the format: 


version=<integer> 


The version number is a numeric integer whose is encoded as the 
<version> parameter defined in ETS 300 709 (e.g. version=100), and 
whose the first digit represents the major VEMMI version number. 
It must be pointed out that the VEMMI objects includes the VEMMI 
version and a timestamp. 
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9B) ENCODING CONSIDERATIONS: 


The "base64" mechanism is preferred because VEMMI use a native 8-bit 
binary file format. However, as VEMMI includes its own 7-bits 
encoding mechanisms, VEMMI data could also be transmitted in 7-bit 
mode. 


9C) SECURITY CONSIDERATIONS: 
Refer to paragraph 8. 

9D) INTEROPERABILITY CONSIDERATIONS: 
VEMMI is designed to be fully platform independent, and the VEMMI 
objects and contents could interoperate between any platform. The 


only exception are the VEMMI operative objects that could be binary 
programs specific to a given hardware platform and operating system. 


10) Liaison address: 
For all technical questions regarding this request, please contact: 


Daniel Mavrakis 

Monaco Telematique MC-TEL 
P.O. Box 225 

MC 98004 Monte-Carlo Cedex 
PRINCIPALITY OF MONACO 
EMail: Mavrakis@mctel.fr 
Tel: (+377) 9216 8860 

Fax: (+377) 9330 4545 


Comments may also be addressed to: 


Mr. Herve Layec, 

ETSI STC TE1 

06921 SOPHIA ANTIPOLIS Cedex 

FRANCE 

EMail: herve.layec@dri.france-telecom.fr 
Tel: (+33) 2 99 12 73 01 

Fax: (+33) 2 99 38 49 61 
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Mr. Kurt Kartmann 

Consulting 

Telecommunication+Multimedia 
Gabelsbergerstr. 2 

D-64807 DIEBURG 

GERMANY 

EMail: k.kartmann@t-online.de 

Tel: (+49) 6071 1528 

c/o Deutsche Telekom AG 

Tel. (+49)6151 834965, Fax (+49) 6151 834284 
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